File management system, method and computer program

ABSTRACT

A file management system that transmits a record file of voice data or image data created by a local device to a center device over a network and manages the record file in the center device. A first device creates the record file and attribute information indicating the attribute about the record file, stores the record file in a first storage unit, and transmits the attribute information to the second device through the network. A second device receives the attribute information transmitted from the first device and stores it in a second storage unit. The second device receives the record file transmitted from the first device according to transfer condition that is beforehand determined and store it in the second storage unit. A terminal may acquire the record file by using the attribute information.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a file management system, method and acomputer program, and more particularly relates to the retention andmanagement of telephone call record files generated in a call center andan office and files of images captured by a monitor camera and so forth.

2. Description of the Related Art

The files of telephone call records (voices) occurring in the callcenter, the office of a sales department or the like, or the files ofimages of persons, background video images and so forth captured by amonitor camera and so forth (hereinafter, referred to as a “record file”or “record files”) are retained in a file management device as recordsincidental to various activities. For example, when the record file oftelephone calls is to be retained and managed, information relating tospecification of a phone number (or information such as an IP address orthe like with which a connecting destination is identified), date andtime of acquisition (that the file has been acquired), or a place ofacquisition, such as the information of identifying an object to beacquired, information on a situation upon acquisition and so forth areretained in the file management device as attribute information byrelating them to the record file concerned. In general, the record fileis stored in a storage in the file management device and the attributeinformation is stored in a database which is under the control of thefile management device by being related to the storage, that is, astorage location that the record file has been stored. The attributeinformation is used by searching the database later when the record fileis to be referred to or as required.

It is desirable to install the storage at a secure location, that is,the storage of the record file is in a place such as a data center orthe like where the files are readily managed collectively from theviewpoint of insuring security. Therefore, it becomes inevitable totransmit the record files from the call center (having a file collectiondevice) that collects the record files to the file management deviceinstalled in a remote location over a network.

As related art of this kind, for example, in Japanese Patent Laid-OpenNo. 2010-219734, there is described a telephone call records centralmanagement system where voice files and attribute files of the voicefiles generated in offices which are decentralized such as salesoffices, branch offices and so forth are transmitted to a centralmanagement server over a network such as a WAN (Wide Area Network) orthe like and are registered in the database of the central managementserver so as to unitarily manage them.

However, since the capacity of the record file is large, such adisadvantage occurs that in a method that every time one record file iscreated on the side of the file collection device, the record file istransferred to the file management device, an amount of the networkbandwidth to be used for file transfer is large and a delay is inducedin transfer of other pieces of data which are high in priority. Formeasures, in which the transfer of record files occurs, there isconceivable a method of transferring the record files collectively in atime zone where room in the network bandwidth is available such as inthe nighttime. Therefore, in the file collection device, we can think ofa method of retaining collected record files in a storage until they aretransmitted to the file management device and transmitting the recordfiles to the file management device when there is room in the network.

In the unitary telephone call records central management systemdescribed in Japanese Patent laid-Open No. 2010-219734, if the recordfiles and their attribute files which are collected and retained by alocal server are collectively transferred from the local server to acentral management server by utilizing a time zone that there is room inthe network, the load which is imposed on the network for file transferwill be reduced. However, since many record files and attribute filesare retained in the local servers in the decentralized offices until therecord files and the attribute files are transferred to and collectivelyretained in the central management server, it is difficult to refer tothem unitarily.

As a solution to the above-mentioned disadvantage, there is alsoconceivable, for example, a method that every time one record file isacquired by each local server, the record file is transferred to thecentral management server. However, in this method, since the frequencyof file transfer in the on-duty time zone in the daytime that manyrecord files are acquired is high it is difficult to transfer the filesby selecting a time zone where the network load is small. Furthermore,there is a demand that searches can be conducted over a wide area byusing attribute information, and that a desired record file can beobtained rapidly.

SUMMARY OF THE INVENTION

The present invention aims to provide a low cost and easy to use filemanagement system which manages a record file made in a local area andattribute information thereof.

In addition, the present invention aims to transfer a record file madein a local area to a center based on a transfer condition of the recordfile according to a user's desire.

More specifically, the present invention aims to reduce the line costand network bandwidth required by transferring the record file from alocal place to a center by utilizing a time zone that the networkbandwidth is readily ensured.

Furthermore, the present invention aims to provide a record file rapidlyto a terminal, request source, by saving the record file to a storagedevice set at the local area, and to make it possible to refer it.

A file management system according to an embodiment of the presentinvention is preferably a file management system that transmits a recordfile of voice data or image data which is created by a first device to asecond device over a network and manages the record file in the seconddevice,

wherein the first device:

creates the record file including the voice data or the image data,

creates an attribute information indicating attribute about the recordfile,

stores the record file associated with information identifying therecord file in a first storage unit, and

transmits the attribute information including the identificationinformation about the record file to the second device through thenetwork,

the first device or the second device beforehand sets the transfercondition on which the record file stored in the first storage unit istransferred to the second device;

wherein the second device:

acquires the attribute information transmitted from the first devicethrough the network,

stores management information including the acquired attributeinformation in a second storage unit,

receives the record file transmitted from the first device according tothe transfer condition after acquiring the attribute information of therecord file,

stores the received record file in the second storage unit, and updatesthe management information stored in the second storage unitcorresponding to the identification information of the received recordfile.

The present invention further provides a file management systemcomprising the second device, a file management method as to the filemanagement system, and a program executed on servers composed of thefirst device and the second device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating a configuration example of a recordfile management system according to one embodiment of the presentinvention;

FIG. 2 a diagram illustrating a configuration example of a local devicein the record file management system according to one embodiment of thepresent invention;

FIG. 3 is a diagram illustrating a configuration example of a centerdevice in the record file management system according to one embodimentof the present invention;

FIG. 4 is a diagram illustrating a format configuration example of anattribute file in one embodiment of the present invention;

FIG. 5 is a diagram illustrating a configuration example of a managementtable for attribute information in one embodiment of the presentinvention;

FIG. 6 is a sequence diagram illustrating an example of a series ofoperations of transferring from a local system to a center system andretaining record files in one embodiment of the present invention;

FIG. 7 is a sequence diagram illustrating an example of an operation ofacquiring an extended additional information according to the secondembodiment of the present invention.

FIG. 8 is a sequence diagram illustrating an example of an operation ofacquiring an extended additional information according to the secondembodiment of the present invention.

FIG. 9 is a sequence diagram illustrating an example of an operation ofacquiring an extended additional information according to the secondembodiment of the present invention.

FIG. 10 is a sequence diagram illustrating an example of a series ofoperations of transferring from a local system to a center system andretaining record files in the third embodiment of the present invention;

FIG. 11 is a flow chart illustrating an example of a series ofoperations of transferring from a local system to a center system andretaining record files in the third embodiment of the present invention;

FIG. 12 is a diagram illustrating an example of a transfer controlcondition table according to the third embodiment of the presentinvention;

FIG. 13 is a sequence diagram illustrating an example of an operation ofsearching a record file from a terminal according to the fourthembodiment of the present invention;

FIG. 14 is a diagram illustrating a search screen of record informationaccording to the fourth embodiment of the present invention in aterminal;

FIG. 15 is a diagram illustrating a search result screen of recordinformation according to the fourth embodiment of the present inventionin a terminal;

FIG. 16 is a diagram illustrating a configuration example of an imagefile management system according to the fifth embodiment of the presentinvention; and

FIG. 17 is a diagram illustrating a configuration of a management tableof attribute information according to the fifth embodiment of thepresent invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following, preferred embodiments of the present invention will bedescribed in detail with reference to the accompanying drawings.

First Embodiment

FIG. 1 illustrates a configuration example of a record file managementsystem according to one embodiment.

The first embodiment is applied to a contact center management systemthat telephone call record files (hereinafter, simply referred to as “arecord file” or “record files”) generated in a call center or centerslocated in one or a plurality of local places are transferred to amanagement device installed in the center and retained in the center.

In one base or a plurality of bases where a call center/call centersis/are located, there is/are formed one or a plurality of local system(s) 2 each including a telephone system 21 which is connected to apublic telephone network 81. One or the plurality of local system(s)is/are connected to a center system 1 over a network 82 such as the WANor the like. A terminal 7 used for monitoring an operating status or thelike of an operator terminal of the telephone system 21 and forreferring to record files (described later) is connected to the WAN 82in some cases.

In the local system 2, the telephone system 21 includes an IP-PBX(Internet Protocol Private Branch Exchange) which is connected to thepublic telephone network 81 and the operator terminal that performsreception of a telephone call which is received through the IP-PBX. Thelocal system 2 further includes a local device 20, a local storage 22, anetwork connection unit 23 which is connected to the WAN 82 and aterminal 27 which is connected to the network connection unit 23.

A call control server 24 acquires and manages call control information(incoming call of telephones, source telephone number, destinationtelephone number etc.) transmitted and received between a PBX of thetelephone system 21 and inner telephones therein through CTI link(Interface (I/F) for call control), information of operator operating aterminal in the telephone system 21, condition information of thetelephone system 21, and information of the terminal.

The local device 20 is configured, for example, by a server device andacquires a telephone call packet (for example, an RTP (Real-timeTransport Protocol) packet) which is transmitted and received betweenthe IP-PBX of the telephone system 21 and an internal telephone set, andcreates a record file 92 on the basis of the packet, and furtheracquires attribute information used for managing the record file 92 andcreates an attribute file 91. The record file 92 and attribute file 91so created are temporarily stored in the local storage 22 and are thentransmitted to the center system 1. (A detailed configuration of thelocal device 20 will be described later with reference to FIG. 2.)

The record files 92 which have been temporarily stored in the localstorage 22 are then collectively transmitted to the center system 1 in apredetermined time zone (that is, a time period in the nighttime whenthe network load is small) and are retained in a storage 12 of thecenter system 1 and managed. (A description will be made later withrespect to this point.)

The terminal 27 is a terminal for a manager that includes an inputdevice, a display, a processor and memory such as a personal computer(PC) and is allowed to monitor the operating status of the operatorterminal and to refer to the record file 92 which has been created inthe above-mentioned manner. Although the record files 92 and attributefiles 91 thereof which have been created by the local devices 20 arerecord files 92 to be unitarily managed by the center system 1, they areretained in the local storage 22 until a transfer request to the centersystem 1 comes as one feature of the present embodiment. When thetransfer request comes, it is allowed to readout the record file 92which has been stored in the local storage 22 and to supply the read-outrecord file 92 to the terminal 27 in accordance with a request from theterminal 27 within the local system 2. Since the terminal 27 is allowedto readily acquire the record file 92 within the local system 2 withoutusing the WAN 82, a reduction in line cost of the network is allowed.

Here, the record file 92 and attribute file 91 thereof will bedescribed. The record file 92 is a file of voices of a telephone calltransmitted and received between a caller and an operator, that is, afile of voices made, for example, for a purchase order, service requestand change, a complaint, confirmation of the contents of a contract froma customer and so forth. Attribute information which would be created asthe attribute file 91 is information which is characteristic to thetelephone call (that is, the record file 92) and includes a start timeand a finish time of the telephone call transmitted and received betweenthe operator and the caller, a source IP address (a port IP address onthe extension side of the PBX), a destination IP address (an IP addressof an extension telephone) and so forth. Here, we call the attributeinformation “basic attribute information”. (A configuration of theattribute file 91 will be described later with reference to FIG. 4.)

Next, the center system 1 includes a center device 10, a center storage12, a network connection unit 13 which is connected to the WAN 82 and aterminal 17 which is connected to the network connection unit 23. Thecenter device 10 is connected to a customer management server 6 througha network connection unit 13. The customer management server 6 is aserver to manage the business operations and customer information of,for example, insurance companies, mail order companies and so forth, andthe center system 1 and plural local systems 2 corresponding to theinsurance companies, mail order companies is for supporting the callcenter of them.

The center device 10 is for example, a server device (a detailedconfiguration thereof will be described later with reference to FIG. 3),and mainly performs a process of retaining the record files 92 and theattribute files 91 which have been collected from the local systems 2and a process of supplying the record file 92 which is retained inaccordance with a request from the terminal 7, 17, and 27.

The center storage 12 stores a management table 122 for managingattribute information that the attribute files 91 indicates and recordfiles 123 (the same as the files 92) which are collected from therespective local systems 2. A configuration of the management table 122will be described later with reference to FIG. 5.

The terminals 7 and 17 are terminals also for the manager such as thepersonal computers (PCs) similarly to the terminal 27, and used tomonitor the operating status of the operator terminal and to refer tothe record file 123 stored in the center storage 12.

FIG. 2 illustrates a configuration example of the local device 20.

The local device 20 includes a record file creation unit 201 foracquiring a telephone call packet from an interface 261 of the telephonesystem 21 and creating a record file 92, an attribute file creation unit202 for creating an attribute file 91 which includes attributeinformation (refer to FIG. 4) such as a record start time and finishtime, recipient information and so forth upon creation of the recordfile 92, a transfer control unit 204 for controlling transfer of theattribute file 91 and the record file 92 to the center device 10 via aninterface 263, and a record file reference processing unit 205 forreading out the record file 92 stored in the local storage 22 inaccordance with an access request from the terminal via an interface262.

Although a hardware configuration of the local device 20 is notillustrated, the local device 20 includes a processor for executing aprogram, a memory or memories for storing data and the program which isexpected to be executed by the processor and so forth. Functions of theabove-mentioned respective units are implemented by executing theprogram on the processor.

The local storage 22 stores the record file 92 which has been created bythe record file creation unit 201 and the attribute file 91 which hasbeen created by the attribute file creation unit 202 and corresponds tothe record file 92. Incidentally, although, in FIG. 2, the local storage22 for storing the attribute file 91 and the corresponding record file92 is illustrated on the outer side of the local device 20, the localstorage 22 may be contained in the local device 20. Furthermore,although, in FIG. 2, the local storage 22 for storing the attribute file91 and the corresponding record file 92 is illustrated that they arestored in the same local storage 22, they may be stored in differentlocal storages 22 respectively.

FIG. 3 illustrates a configuration example of the center device 10.

The center device 10 includes an attribute file processing unit 101 forperforming a process of extracting information to be retained in themanagement table 122 from the received attribute file 91 and a processof updating the contents of the management table by relating thecontents to the record file identification ID, a record file retentionand management unit 102 for storing the received record file 123 in thecenter storage 12, a table management unit 103 for writing and readingout information into and from the management table 122 which is storedin the center storage 12, a record file reference processing unit 105for searching the management table 122 and reading out the record file123 stored in the center storage 12 in accordance with a referencerequest from the terminal 17, an extended additional informationprocessing unit 106 for acquiring an added information associated withbasic attribute information of record files (called “extended additionalinformation”) from the IP-PBX, call control server 24, or customermanagement server 6 and processing the extended additional information,and a file transfer control unit for controlling transfer (sometimescalled “upload”) of the record files from the local system 2 to thecenter system 1, and a transfer control condition setting unit 108 forprocessing registration of transfer condition specified from a recordfile transfer control unit 107 and the terminal 17, to a transfercontrol condition table 124.

Although a hardware configuration of the center device 10 is notillustrated, the center device 10 includes a processor for executing aprogram, a memory or memories for storing data and the program which isexpected to be executed by the processor and so forth. Functions of theabove-mentioned respective units are implemented by executing theprogram on the processor.

Incidentally, although, in FIG. 3, the center storage 12 for storing themanagement table 122 and the corresponding record file 123 isillustrated on the outer side of the center device 10, the centerstorage 12 may be contained in the center device 10. Furthermore,although, in FIG. 3, the center storage 12 for storing the managementtable 122 and the corresponding record file 123 is illustrated that theyare stored in the same center storage 12, they may be stored indifferent center storages 12 respectively.

The center storage 12 stores the management table 122 composed of eachentry as a management file which is associated basic attributeinformation (a first attribute information) acquired from the localsystem 2 and extended attribute information (a second attributeinformation) included in an attribute file 91 with the record file 123,the many record files 123 transferred from the local system 2 andacquired, and the transfer control condition table 124 specifying uploadtransfer condition of the record file 123. The transfer condition storedin the transfer control condition table 124 is parameters used at thetime when the upload transfer of the record file 123 is executed. (Thematter will be described later). The data in the transfer controlcondition table 124 can be set and changed through the managementterminal interface 265 of the terminal 17 and transfer control conditionsetting unit 108. Incidentally, although the management terminalinterface 265 is the same as the terminal interface 262 in physicalview, we have illustrated different things in the logical view that themanagement terminal interface 265 should be distinguished as the meaningthat it is exclusive interface for an administrator. Incidentally, aconfiguration of the management table 122 and will be described laterwith reference to FIG. 5 and FIG. 12 respectively.

The attribute file 91 transmitted from the local device 20 is processedby the attribute file processing unit 101 and information which isdesirable for an updating process in the table management unit 103 issent to the table management unit 103. Thus, the contents of themanagement table 122 are updated. That is, an entry of new managementinformation added one by one. In the present embodiment, in attributeinformation composing one entry of the management file 122, the basicattribute information is included in the attribute file 91 transferredfrom the local system 2, and the extended attribute information (numbersin FIG. 5, #14-20) is acquired from a PBX or the call control server 24,the customer management server 6. Incidentally acquiring processing forthe management information will be later with reference to FIGS. 6-9.

When receiving the record file 123, the record file retention andmanagement unit 102 stores the record file 123 to the center storage 12.At the same time, the address of the record file 123 is transmitted tothe table management unit 103 because update of the stored placeinformation of the record file 123 in the management table 122 isneeded. The table management unit 103 rewrites the record file receptionflag from not received “0” to received “1”. When, from the terminal 17(or 7), occurring the referring request for the record files 123 stored(or which may be stored) in the center storage 12, the record filereference processing unit 105 receives the request, the table managementunit 103 performs searching process of the management table 122, andnotifies the terminal 17 (or 7) of the result. As a result of referringthe reception flag of the management table 122, when the record file 123which is the target for the referring request is stored in the centerstorage (the record reception flag: “1”), the table management unit 103reads the target record file 123, and transmits it to the terminal 17(or 7). To the contrary, As a result of referring the reception flag ofthe management table 122, when the record file 123 which is the targetfor the referring request is not stored in the center storage (therecord reception flag: “0”), the table management unit 103 refers to“the stored place address of the record file” in the management table122, and transmits a read instruction for the record file to the localstorage 22 in the local system 2, which is indicated by said storedplace address of the record file.

FIG. 4 illustrates a format configuration example of an attribute file.

The attribute file 91 includes each information such as anidentification ID for identifying a record file 92 concerned, a recordstart time (year-month-day-hour-minute-second) indicating the time thatrecording of a telephone call with the caller via the telephone system21 is started, a record finish time (year-month-day-hour-minute-second)indicating the time that recording is finished, a record time(hour-minute-second), a source IP address (a port IP address on theextension side of the PBX) of the record file and a destination IPaddress (an IP address of an extension telephone), a storage locationaddress indicating the storage location of the record file concerned, acall source telephone number indicating an extension telephone number ofa call source, a call destination telephone number indicating an outsideline telephone number or extension telephone number of a calldestination, an outcoming/incoming type indicating whether call from atelephone is outcoming or incoming.

Here, the source IP address and the destination IP address are acquiredfrom a header field of a telephone call packet outside line telephonenumber concerned. In addition, the storage location address is anaddress (for example, a local device address and directory informationin the local storage concerned) of the local device that the record fileconcerned is stored). Further, the call source telephone number or thecall destination telephone number are acquired in the way that thesystem monitors the packet for call control, or acquires informationwhich the telephone system 21 keeps through a CTI link.

FIG. 5 illustrates a configuration example of a management table forattribute information.

The management table 122 is composed of each entry, an identification IDfor identifying the record file concerned, a record start timeindicating the time that recording of the telephone call with the callervia the telephone system 21 is started, a record finish time indicatingthe time that recording is finished, a record time, a source IP address(the port IP address on the extension side of the PBX) of the recordfile and the destination IP address (the IP address of the extensiontelephone) of the record file, a storage location address indicating thestorage location of the record file concerned, a record file receptionflag indicating the reception of the record file finishes in the centersystem 1, a local cash flag indicating the record flag remains in thelocal storage, a storage location address of the local cash used whenthe record file is stored as cash, a call source telephone number, acall destination telephone number, an outcoming/incoming type, a calleroutside line telephone number, an incoming (outside line) telephonenumber, an extension telephone number, an operator id for identifying anoperator who operates in the telephone system 21 in the call center, acustomer identification information (customer name) uniquely given toeach customer of a service company whose business is dealing withcustomers in the call center, a contract conclusion flag indicating thecontent of telephone call is the conclusion of the contract with thecustomer, a complaint flag indicating the content of a customer's callis a complaint, a reference number counter indicating a cumulativenumber at which the terminal refers to corresponding managementinformation of management table 122.

Here, item number #8, the reception flag is the flag indicating whetherreception of the record file corresponding to entry information alreadyregistered in management table 122 is finished or not. And whenreceived, it is indicated with “1”, while when not received, it isindicated with “0”.

With respect to the source of acquisition of management information,information of item numbers #1-7, #11-13 is acquired from the attributefile, and information of item numbers #14-20 (extended additionalinformation) is acquired from the attribute file from a PBX or the callcontrol server 24, the customer management server 6 by the extendedadditional information processing unit through an extended additionalinformation interface 264.

Incidentally, when there are plural local systems, a management table122 is set to each of local systems, respectively, each of managementtables 122 is given to a local system ID for identifying with each localsystem. For another aspect of the system configuration, the pluralmanagement tables 122 may compose a single table.

At the terminal 17, an administrator refers to management informationregistered in management table 122 for analysis, so that he can use itfor analysis of customers and service quality. (Incidentally, referringprocessing for management information will be described with referenceto FIGS. 14 and 15.)

Furthermore, the record file 92 whose reference times are large in thelocal system 2 is used as cash, and left in local storage after thetransfer of the record file finishes. And the center system 1 managesthe situation, so that the administrator can refer to and use saidrecord file rapidly stored in the local storage 22 without transferringsaid record file from the center storage 12 through a WAN, when areference request for said record file occurs from the terminal 27 inthe local system 2.

Second Embodiment Transfer and Retention of the Attribute File and theRecord File

The transfer of information between the local system 2 and the centersystem 1 mainly includes the processing (phase 1) to transfer to thecenter system the attribute file composed of attribute information (wecall it “a first attribute information”) indicating the attribute of therecord file made in the local device 20 and register the attribute fileto the management table, the processing (phase 2) to acquire extendedadditional information (we call it “a second attribute information”)added on the first attribute information corresponding to the recordfile and register the extended additional information to managementtable, and the processing (phase 3) to transfer the record file storedin the local storage 22 to center system and store in the center storage12.

First, with reference to FIG. 6, we describe the whole processing oftransferring the attribute information and the record file from thelocal system 2 and the center system 1, and of storing them. And then,with reference to FIGS. 7-9, we describe the processing of acquiring thesecond attribute file and of registering (Second Embodiment), further,with reference to FIGS. 10-13, describe the control processing oftransferring of the record file (Third Embodiment).

<The Processing of Transfer of the Attribute Information, of Acquisitionof the Extended Additional Information, and of Registering (Phase 1 and2)> (Phase 1)

With reference to FIG. 6, the local device 20 acquires a voice packetfrom the interface 261 to a telephone system, the record file creationunit 201 creates a record file 92, and the attribute creation unit 201creates an attribute file 91 (refer to FIG. 4) including the attributeinformation of the record file. The created record file 92 and attributefile 91 thereof are stored in the local storage 22.

Here, the file creation unit 202 generates unique information (recordfile ID) to identify record files, and gives it to the record file. Therecord file 92 are given the record file ID and stored in the localstorage 22. Further, the attribute file creation unit 202 records “i” tothe record file ID in the attribute file A1, creates the attribute filerecorded the address of the local storage 22 “p1” to the record filelocation address, and stores the attribute file in the local storage 22.

The transfer control unit 204 transfers the attribute file A1 made asabove mentioned to the center system 1 through the center systeminterface 263. This action is performed at every time whenever a newrecord file is made.

At the center storage 10 in the center system 1, the attribute fileprocessing unit 101 transfers management information to be written tothe management table 122 based on the received the attribute file. As tothe example, the record file ID is “i”, the reception flag is notreceived “0” because the record file has not yet received. The mademanagement information is written to items, item numbers #1-#7, and#11-#13 in the management table 122 by the table management unit 103.

(Phase 2)

Next, the system switches to the processing of phase 2. The processingof phase 2 is the phase that the center system 1 acquires the secondattribute information A2 related to the record file from a PBX or thecall control server, the customer management server, and registered tothe management table. As to these, we describe with reference to FIGS.7-9.

As shown in FIG. 7, at the timing of completion of telephonecommunication, the center system 1 acquires the second attributeinformation A2 related to the record file, like the caller outside linetelephone number, the incoming outside line telephone number, and theextension telephone number, from a PBX or the call control server, thecustomer management server, and registers to the item numbers #14-16 ofthe management table. As to these information, the extended additionalinformation processing unit 106 of the center device 10 acquires theinformation kept by the telephone system 21 through the networkconnection unit 13, the extended additional information interface 264,the WAN 82, and the network connection unit 23 in the local system 2.Incidentally, when, in the telephone system 21, the local device canmonitor and analyze the call control packet from the PBX, it may acquirethe above mentioned information without using the CTI link in somecases.

And then the table management unit 103 searches the information of themanagement table 122, decides consistency between the acquired extendedadditional information and the already acquired the first attributeinformation, so that it registers the acquired additional information atthe places of the items corresponding to the first attributeinformation. As to the decision of the consistency, the table managementunit 103 decides it on the basis upon whether each of the destinationand transmission source IP addresses of the packet for calling agrees ornot based on the time of start and end of the telephone call.

Next, as shown in FIG. 8, at the timing of completion of telephonecommunication, the center system 1 acquires the operator IDcorresponding to the telephone number from the call control serve 24. Todescribe in detail, the extended additional information processing unit106 acquires as one of the information included in the call attributioncontrol information through the network connection unit 13, the extendedadditional information interface 264, the WAN 82, and the networkconnection unit 23 in the local system 2. Incidentally, the decision ofthe consistency between this extended information (operator ID) and theabove mentioned first attribute information is performed on whether eachof the telephone numbers agrees or not based on the time of start andend of the telephone call.

Next, after recording the extended attribute information correspondingto the operator ID, as shown in FIG. 9, the extended additionalinformation processing unit 106 of the center device acquiresinformation such as customer identification information, the contractconclusion flag, the complaint flag, and registered them to the itemnumbers #18-20 in the management table. The customer management server 6manages personal information such as customer's name, address, contactaddress (telephone number or E-mail address etc.), age, and job, orcustomer's information such as the content of the contract (currentstatus) etc. with the start and end time of serving the customer, andthe operator ID, so that the decision of the consistency between theabove acquired first attribute information and the above mentionedinformation acquired by the customer management server 6 is performed onthe basis of whether each of the operator Ids whose operator serves thecustomer at the time agrees or not based on the time of start and end ofthe telephone call. Thus, the attribute file A1 of the first attributeinformation for a record file and the second attribute information A2,the extended additional information related to the first attributeinformation are collected, and one entry of the management informationcorresponding to said record file (record file ID) is formed in themanagement table. At this stage, the system keeps the condition that therecord file is retained in each of local storages 22 in the local system2, and the center system 1 has not yet received the record file (#8record file reception flag: “0”). Further, the record file storagelocation address #7 is the local storage location address “p1”.Moreover, the local cash flag #9 and the local cash storage locationaddress is unregistered.

These operations of phase 1 and phase 2 as above mentioned are repeatedat each time when each record file is created.

Thus, the first attribute information that the local system 2 makesbased on the packet for using call acquired from the telephone systemdirectly is not only collected but also information including the secondinformation related to the first attribute information, which theextended additional information processing unit 105 of the center device10 acquires. This management information is, after that, used for thesearch based on various information included in the managementinformation, so that an administrator can acquire the record file by thesearch in wide view using various information. By listening to therecord file, the result of the search, the administrator cab confirm theconversation between the operator and the customer, or the reception onthe business, and monitor. These matters are profitable for arrangementof operators, business management, or customer management.

Alternative Example

Incidentally, an attribute file is transmitted to the center system 1 bythe attribute file creation unit 202 at each time when the attributefile creation unit 202 creates the attribute file. However, according toan alternative example, created record files is stored temporarily,after that and at every time after a lapse of a certain time (forexample, one hour), the local system may transmit in a math together theplural created record files stored in the local storage 22 to the centersystem.

Third Embodiment Transfer Control of the Record File (Phase 3)

Next, with reference to FIGS. 10-12, we describe the transfer controlprocessing of the record file from the local system to the centersystem.

First, with reference to FIG. 12, we describe the configuration exampleof the transfer control condition table 124. The transfer controlcondition table 124 registers information such as a transfer start timeof the record file, a record time of the record file, an incomingoutside line telephone number, a contract conclusion flag, a complaintflag, a reference number, and the like. These information are registeredby the way that an administrator specifies from the terminal 17. Here,the contract conclusion flag, the complaint flag, the reference numbercounter are the suppression condition, if at least one of these setconditions is fulfilled, the upload of the record file is suppressed.For one example, we can specify a nighttime zone (for example, “0 a.m.”)that the network cost is low for the transfer start time of the recordfile. Further, we can specify “one week after recording” for the recordperiod of the record file. Incidentally, it is possible that the recordperiod of the record file is not specified. The incoming outside linetelephone number is able to be specified a telephone number for aparticular service or a telephone number income from a particular area(for example, Tokyo: area code “03-”). Moreover, it is possible that theincoming outside line telephone number is not specified. Although we canset to the contract conclusion flag, or the complaint flag, it ispossible that they are not specified. The reference number is the numberof count of the reference to the attribute file or record file from theterminal. It is preferable that the record file whose reference numberis large than the specific number, is left in the local system, becausethat means the record file is much more likely to be referred by theadministrator, and the record file whose reference number is less thanthe specific number, is transferred to the center system.

Incidentally, when there are plural local systems, the transfer controlcondition table 124 is configured corresponding to each of the localsystems. At the case, it is preferable that the transfer start time ofthe record file in the transfer control condition table 124 is specifiedin the distributed way in the nighttime zone that the network cost islow. For, if plural local systems start to transfer record files at thesame time, it is rather capable of occurring the congestion of theactions of storing the record file and updating the attributeinformation because many receiving of the record file are concentratedin the center system.

Next, with reference to FIGS. 10 and 11, we describe processes oftransferring the record file and retention of the record file.

We set the assumption that the record file is kept in the local storage22, and information of the first attribute information and the secondattribute information corresponding to the record file finishes beingregistered in management table 122.

In FIG. 10, the process of transferring the record file stored in thelocal storage 22 to the center system 1 starts from the transmission oftransfer control condition and transfer request issued from the filetransfer control unit 107 in the center device 10. The selection ofissuing the transfer request and the record file to be transmitted isperformed in accordance with the condition registered in the transfercontrol condition table 124. In the case of this example, the time thatthe current time kept in a timer of the center system 1 becomes therecord file transfer start time (0 a.m. (time zone: the bandwidth in thenetwork is easy to be reserved)), the record file transfer control unit107 issues the transfer control condition and transfer request.

Next, as to the example of selection of the record file which is theobject of upload based on the transfer control condition, with referenceto FIG. 11, we describe in detail.

The aim of this example is that the record file whose referencefrequency is large still remains storing in the local storage 22 withouttransferring to the center system 1, so that the objective record filecan be provided in a short time for the request from the terminal 27 inthe local system 2. That is, when the objective record file is readimmediately from the local storage 22, and transferred to the terminal27, the transfer time can be reduced substantially, and the line costcan be saved in comparison with the case of transferring the record filestored in the center storage 12. Further, it is unnecessary to transfer(called “upload”) the record file to the center system 1.

Next, we describe the process of FIG. 11. First, the transfer control204 judges whether the record period is within the designated range ornot with reference to the information in the management table 122(S1101). It judges, for example, whether one week passes after therecord end time in the attribute information, the record file becomesthe object of upload when one week passes (S1101: YES). That is, theimportant point is as following: the record file remains storing in thelocal storage 22 (S1101: NO), when one week has not yet passed afterrecording to the record file (recently recorded), because the referencefrequency of the record file rather has a tendency to be large; and tothe contrary, when one week has already passed after recording to therecord file (old one), the record file is uploaded (S1101: YES) and keptin the center storage 12, because the reference frequency of the recordfile is reduced.

Next, the transfer control 204 judges whether the incoming outlinetelephone number indicating the content of reception work is within thedesignated range or not (S1102). As to the incoming outline telephonenumber, multiple specification is possible. The incoming outlinetelephone number is judged with #15 incoming outline telephone number ofthe attribute information. When the incoming outline telephone numberwithin the designated range, said record file becomes the object ofupload.

Next, the record file becomes the object of upload when the attribute isthe following: flag negative “0” in the judgment about the contractconclusion flag (S1103); flag negative “0” in the judgment about thecomplaint flag (S1104); and less than or equal to the designated number(for example, less than or equal to one) in the judgment whether thereference number counter is within the designated range or not (S1105).That is, when the contract conclusion flag or the complaint flag is “1”(positive), or its the reference number counter is more than thedesignated number, said record file is not uploaded, and is allowed tobe easy to use. The transfer control unit 204 in the center system 1reads the entire record file IDs whose attribute is satisfied with theabove mentioned transfer control condition, and transmits them to thelocal system 2.

When the transfer control unit 204 of the local device 20 receives oneor multiple record file IDs transmitted from the center device 10, thetransfer control unit 204 reads the record file 92 according with saidrecord file IDs in non-transferred record files stored in the localstorage 22 sequentially, and hence, transmits them to the center system1.

In the center system 1, the record file retention and management unit102 in the center device 10 receives the transmitted record filessequentially, and stores them to a record file storage area in thecenter storage 12. For example, when the record file retention andmanagement unit 102 receives the record file whose record file ID is “i”and stores to the record file storage area, the record file retentionand management unit 102 transmits to the table management unit 103 therecord file ID “i” and the address (center storage location address)“q1” at which the record file is stored. The table management unit 103rewrites the reception flag #7 corresponding to the record file “i” fromnot received “0” to already received “1”, and rewrites center storagelocation address to “q1”. Hence, the storage destination addresses andreception flags corresponding to the record file ID through all thereceived record files are changed, and the content of the managementtable is updated. Consequently, when the center device 10 receives allthe record file according with transfer control condition, the recordfile transfer control unit 107 issues the instruction “transfersuppression” of record files. After that, the condition, transfersuppression is kept until the next transfer request is issued.

<About Local Cash>

In this case, even when the record file is transferred from the localstorage 22 to the center system 1, the record file is left to the localstorage 22, the local storage 22 is used as what is called “cash” of thecenter storage 12. The local cash flag for this usage is set to “1”, andthe local cash storage location address is registered to the address.For example, the local cash storage location address of the record file“i” is “p1” as the same as the previous address. Comparatively a lotaccess requests such as search or the like is executed from the samelocal system when the record file is created at the beginning. If wecompare the case that the record file stored in the local storage 22 ascash is transferred to the terminal 27 in the same local system 2 andthe case that the record file stored in the center storage 10 istransferred to the terminal 27, the network load and cost are low in theformer case, therefore, the former case is more effective.

Incidentally, the deletion of the record file stored in the localstorage 22 is possible by the instruction from the file transfer controlunit 107. For example, the file transfer control unit 107 transmits acash clear request added the record file ID for the object of deletion,and the local device 20 deletes the record file corresponding to thetransmitted record file ID from the local storage 22. After thedeletion, the local device 20 notifies the center device 10 of thematter, the table management unit 103 rewrites the local cash flagcorresponding to the deleted record file to “0”, and deletes said localcash storage location address. It is possible to issue the cash clearrequest for example, in the way that the file transfer control unit 107monitors elapsed time from the date and time of acquisition of therecord file (for example, record end time), so that the file transfercontrol unit 107 issues the cash clear request in sequentially to therecord file passing for definitely period (for example, one month).

Alternative Example

In the above mentioned third embodiment, the transfer request andtransfer control condition are transmitted from the center device 10 tothe local system 2. However, according to this alternative example, itis possible that the transfer request is issued first from the localdevice 20 to the center device 10, the center device 10 refers to thetransfer control condition table 123, judges whether transfer isadmitted or not (judges whether the transfer start time comes or not),and transfers the transfer request and transfer control condition to thelocal system.

Further, another alternative example, when the setting condition in thetransfer control condition table 124 does not include that of the secondattribute information, but includes only that of the first attributeinformation, this transfer control condition table 124 may be kept inthe local storage. In this case, we provide a transfer control conditionsetting unit 108′ in the local device 20, and can set or change thetransfer control condition by the transfer control condition settingunit 108′ in accordance with the request from the terminal 17 for anadministrator at the same as the transfer control condition table 124 inthe center storage 12. Incidentally, the issue of the transfer requestand the transfer control of the record file is in the same way as theabove embodiments, that is, the transfer control unit 204 in the localdevice 20 reads the record file stored in the local storage 22 inaccordance with the condition registered in the transfer controlcondition table 124′ in the local storage 22, and transmits to thecenter system 1.

Further, in the above embodiments 2 and 3, although the action of phase3 is performed after the phase 2, according to other alternativeembodiment, the action of phase 3 may be performed before the phase 2.According to this, acquisition of the extended added management tablefor the management table 122 is delayed, however, retention of therecord file in the center storage 12 can be advanced. At the result, theterminal 17 in the center system can search the basic information andacquire the record file from the center storage rapidly and in low cost.

Fourth Embodiment

Next, with reference to FIGS. 13-15, we describe the search process andreference process.

FIG. 13 (A) illustrates the case that the record file is in the localstorage 22, and (B) illustrates the case that the record file is in thecenter storage 12. Further (B1) illustrates the case that the recordfile is in both the center storage 12 and the local storage 22 (cashfunction), and (B2) illustrates the case that the record file is only inthe center storage 12.

We assume that an administrator operates an input device of theterminals 7, 17, 27, allows to display the search screen as shown inFIG. 14 in the display screen of a display device, and performs thesearch of the record file. The search items includes attributeinformation managed in the management table 122, the first attributeinformation and the second attribute information (extended additionalinformation). The administrator operates the input device of theterminals, and designates or inputs the content of the item which hedesire to search, so that search condition is created. As to the searchcondition, he can designate the item about the following case: forexample, he investigates the condition of listening of a specificoperator (operator ID); he listens the record in a specific time zone orreceived at a specific extension telephone number; he listens thecontent of complaint from a specific customer (customer name (customerID)); and the like.

After the administrator inputs (designates) the item about the searchcondition, when he operates a “search execution” button, the requestincluding the search condition is issued from the terminal. The searchrequest is transmitted to the center device 10 in the center system 1respectively: when the search request is issued from the terminal 27, itis transmitted through the network connection unit 23 and the WAN 82;when the search request is issued from the terminal 7, it is transmittedthrough the WAN 82; and when the search request is issued from theterminal 17, it is transmitted through the network connection unit 13.

When the center device 10 receives the search request through theterminal interface 262, the record file reference processing unit 105searches the management table 122 based on said received searchcondition. And then, the record file reference processing unit 105transmits the search result to the terminal of request source throughthe terminal interface 262.

In the terminal of request source, the search result display screen asshown in FIG. 15 is displayed. Incidentally, the information of thesearch result transmitted from the center device 10 includes theinformation not displayed on the display screen. For example, itincludes the record file reception flag and the record file storagelocation address, or the local cash flag and the local cash storagelocation address.

On the search result screen, “reference flag” and “deletion flag” aredisplayed in addition to items corresponding to the record file IDaccorded with the search condition. The administrator selects the“reference flag” of the record file which he desires to refer (inputscheck mark), operates an “execution” button, then the system moves tothe process of acquisition the selected record file. As the actions upto this stage, the cases of FIG. 13 (A) and (B) are the same.

As shown in (A), when there is no selected record file in the centerstorage 12 (record file reception flag “0”), but is in the local storage22 (the case of the record file ID “m”), the terminal accesses to thelocal device 20. The access request is accompanied with the address “p1”of the local storage.

When the local storage 20 receives the access request, the local storage20 reads the record file corresponding to the address “p1”, andtransmits it to the record file reference processing unit 205. And therecord file reference processing unit 205 transmits the record file 92corresponding to the address “p1” to the terminal of request source.

To the contrary, as shown in (B1), when there is the selected recordfile in the center storage 12 (the case of the record file ID “k”), theterminal refers further to the local cash flag and the local cashstorage location address. In the result, when there is the objectiverecord file in the local storage (local cash flag “0”), the terminal(mainly, terminal 27) issues the access request accompanied with thelocal cash storage location address “p1” to the local device 20. Whenthe local device 20 receives the access request, the local device 20reads the record file stored at the local cash storage location address“p1” from the local storage 22, and transmits it to the terminal ofrequest source at the same as the above mentioned actions.

However, as shown in (B2), when there is no selected record file in thelocal storage (local cash flag “0”), the terminal issues the accessrequest accompanied with the local cash storage location address “q1”.In the center device 10, when the record file reference processing unit105 receives the access request through the terminal interface 262, therecord file reference processing unit 105 reads the record filecorresponding to the address “q1” from the center storage 12, andtransmits the record file to the terminal of request source the terminalinterface 262.

As mentioned above, the record file selected by the administrator istransmitted to the terminal of request source from the local storage orthe center storage. The administrator can play the record file, andlisten to the content.

Although, one or multiple record files created in the local system 2 iscollected, kept and managed finally in the center system in accordancewith the above mentioned transfer condition, when the local storageworks as cash, and the record file is stored also in the local storage22, the terminal 27 can acquire the objective record file from the localstorage in the local system rapidly. As the result, communication costof the network can be reduced.

Incidentally, in the selection action mentioned above, when the action“deletion” is selected, the deletion request accompanied with theobjective record file ID is transmitted from the terminal to the centerdevice 10 or the local device 20. When receiving the deletion request,the record file retention and management unit 102 deletes the recordfile of the designated record file ID from the center storage, and thetransfer control unit 204 deletes the designated record file from thelocal storage 22.

Fifth Embodiment The Example of an Image File Management System

FIG. 16 illustrates a configuration example of the local system of animage file management system applied to an entrance and exit managementsystem of an Office or the like.

We can think the local system applied to the call center as to therecord file management system is replaced with the local system as theimage file management system. Although the basic structure of the centersystem 1 shown in FIG. 1 does not change, the record file 123 andmanagement table 122 change to the table which manages image files andthe attribute information and the related information (addedinformation) thereof.

The entrance and exit management system shown in FIG. 1 comprises anentrance and exit management device 25, a local device 20′, a localstorage 22′, a network connection unit 23′, and a terminal 27′. Here,because the configurations and functions of the entrance and exitmanagement device 25, the local device 20′, the local storage 22′, thenetwork connection unit 23′, the terminal 27′, and the like are the sameas the configurations and functions shown in FIGS. 1 and 2, or we canunderstand easily from those, we omit those explanation.

The entrance and exit management device 25 is a kind of a server, andhas a processor (CPU) which executes programs, and processes data, amemory, a storage device, and the like. The entrance and exit management25 comprises further a door open-close control unit 251 which controls adoor with an electronic lock 26 through an electronic lock controlinterface, a card reader 252 which reads information of a IC card that aperson entering a room has, and a monitor camera 253 to image a face ofthe person entering a room, or the person itself. In this embodiment,although the image file of the person acquired by the monitor camera 253is finally transmitted to the center system and managed in the centerstorage, ahead of these actions, the attribute information of the imagefile is transmitted to the center system, so that the search of theimage file is made possible. When we call “entrance and exit managementdevice 25”, it means actions and functions executed by the way that theprocessor in the entrance and exit management device 25 runs programs.

A person who has an ID card comes to the entrance in the office to whichor from which he enters or exits, and allows the ID card to read by thecard reader 252 set in the neighborhood of the door. The entrance andexit management device 25 compares the authentication information of IDcards acquired by the card reader 252 with the authenticationinformation of ID cards for the person permitted to enter the roomstored in a storage device (not shown in figures), that is, checks theirconsistency. In the result, when the authentication succeeds, theelectronic lock 26 of the door is released by the door open-closecontrol unit 251. Further, when the monitor camera 253 acquires theimage of the person allowing the ID card to read by the card reader 252(the person whose authentication succeeds or not as the result), theentrance and exit management device 25 transmits the image to the localdevice 20′.

The entrance and exit management device 25 further transmits anauthentication time of the ID card, an authentication completion time ofthe ID card, an authentication result, and the like to the local device20′, at each time when the entrance and exit management device 25acquires them. In the local device 20′, an image file creation unitcreates the image file in the way that the image data is converted intoelectronic file format, gives a specific image file ID to each createdimage file, and stores in the local storage 20′. Further, an attributefile creation unit create an attribute file composed of information(here, called “basic attribute information”) such as an image file ID,an authentication time of the ID card, an authentication completion timeof the ID card, an authentication result, and the like, and information(here, called “basic added information”) such as a door ID to identifywith the door issuing an request to be opened, an ID card number toidentify with the IC card, an authentication result indicating whetherthe authentication succeeds or not, and the like, and transmits theattribute file to a center system 1′.

Further, as an alternative example of the configuration, it is possiblethe server device, the entrance and exit management device 25 has somefunctions which deal with the image file kept in the local device 20′ asparts of its functions.

FIG. 17 illustrates a configuration example of an attribute informationmanagement table to manage attribute information of image files.

The management table 122′ kept in the center storage 12′ of the centersystem 1′ is composed of the basic information as to an image fileacquired by the monitor camera and the information of acquisition forthe image file, and the added information as to not the image fileitself, but rather the person generating the image file (image of thebody) or items (ID card) which the person possesses. The addedinformation is composed further of the basic added information and theextended additional information.

The basic added information includes an ID to identify with the imagefile, a record start time indicating a time at which the monitor camerastarts to record, similarly a record end time indicating a time at whichthe monitor camera finishes to record, a record time, an authenticationstart time to start to authenticate for the entrance of a person havingthe ID card, similarly an authentication end time to finish toauthenticate, a storage location address indicating a location at whichthe local storage or the center storage stores the image file, areception flag indicating that the center storage receives the imagefile, a local cash flag indicating that the image file is stored in thelocal storage 22′, receives, a cash location address used when the imagefile is stored as cash in the local storage, and the like.

The extended additional information includes a door ID to identify withthe door issuing an request to be opened, an ID card number to identifywith the IC card, an authentication result indicating whether theauthentication succeeds or not, and the like. Further, the extendedadditional information includes a reference counter indicating acumulative number at which the ID card user name or its attributeinformation is referred, and the like. As to the attribute information,the ID card user name (personal information of the card user) and thelike, after the center device acquires the basic added information andthe extended additional information of the image file, and stores it inthe management table, the center device acquires the attributeinformation as the personal information of the person having the ID cardfrom a personnel management server (not shown in figures) connected tothe center device.

Because, in the image file management system configured as the abovementioned, a transfer control of the image file from the local system 2′to the center system, a search for the image file and its attributeinformation using the image file management system are the same as thefirst embodiment, we omit explanation of these matters.

According to this embodiment, the fifth embodiment, we can get the sameeffect as the first embodiment such that the transfer time zone of theimage file is set to the time zone in which reservation of the networkbandwidth is easy and so forth. Further according to the entrance andexit management system, early treatment for security is possible by theway that the system gives high priority to transmission of the imagefile of the person who does not succeed in his authentication. Moreover,the customer service can be reinforced by the way that the system giveshigh priority to transmission of the attribute file of the outsidepersons such as customers or the like.

Incidentally, as the alternative example of the fifth embodiment, it ispossible to use the camera acquiring the image of the finger print orthe vain of the person who enter from or exit to the door, instead ofthe monitor camera 253 imaging the person's body. Also in this case,surely we can get the same effect as the fifth embodiment.

Moreover, as another example, this invention can be applied to thesystem comprising a monitor camera set to interchange gates in highwaysand an ETC device. The monitor camera acquiring the image of a car or adriver acquires the image and its attribute information (the firstinformation), and the ETC device acquires personal information(corresponding to the second information), so that the attributeinformation and the image file can be transferred to a center andmanaged.

We can present various alternative examples of the above mentionedembodiments 1-5.

For example, in the above embodiments, although the management table 122and the record file are stored in the same storage, it is not alwaysnecessary to store in the same storage. The management table 122 can bestored in the store device such as a semiconductor memory the memory setin the server, whose storage capacity is comparatively smaller, whilethe record file can be stored in the mass capacity storage. Further, wementioned the contact center management system that a record filegenerated in the call center is transmitted to the center system, andmanaged in the center system. Here, it is not always necessary that thecenter system is a host computer specified in advance or something.According to an application, the center system may be, for example, aserver or computer which is specified by a user or a company entrustedoperations in the call enter.

Further, in the above embodiment, although we call a record voice fileor image file “record file” generically, various ways of calling arepossible. For example, it may be called a record log of a voice, image,or video, further, it may be called “a contents file of a voice”, or “acontents file of image”.

According to the some embodiments mentioned above, first, the attributeinformation of the record file created in a local base point istransmitted to the center device, and managed as a managementinformation, after that, the center device acquires the record file. Wecan set transfer control conditions in various ways to transmit therecord file stored in a storage set in the local point to the centersystem, so that various types of transfer control are possible. Forexample, as to the time at which the record file is transmitted, we canset to the time zone such as a night time zone or the like, in which thebandwidth is easy to reserve, so that the necessary network bandwidthcan be reduced, and the line cost can be decreased.

Further, we can search the record file in wide and various view pointsby the way that the system manages not only the attribute informationacquired from a device set in a local point, but also the attributeinformation acquired from another device as management information, andsearches the latter attribute information.

Furthermore, the search for and reference to the record file is easyfrom the terminal 27, because the record file is stored at a certainperiod in the local storage 22. In the case of the call center, thereare needs that an administrator or operator wishes to listen once moreto the content of the record of call occurring in the same place, andthese needs can be satisfied.

In this case, time for playback of the record file can be reduced,because download of the record file from a center through a WAN is notnecessary in the reason that the record file saved as cash in the localstorage 22 is read directly from the terminal 27 in the local basepoint.

Further, concentration management of record of telephone calls ispossible while we ensure security of the record file, because for theuser who wishes to leave the record file in the viewpoint of security,without transmission of the record file to a center, only the attributefile can be transmitted to the center, and managed.

What is claimed is:
 1. A file management system that transmits a recordfile of voice data or image data which is created by a first device to asecond device over a network and manages the record file in the seconddevice, wherein the first device: creates the record file including thevoice data or the image data, creates an attribute informationindicating attribute about the record file, stores the record fileassociated with information identifying the record file in a firststorage unit, and transmits the attribute information including theidentification information about the record file to the second devicethrough the network, the first device or the second device beforehandsets the transfer condition on which the record file stored in the firststorage unit is transferred to the second device; wherein the seconddevice: acquires the attribute information transmitted from the firstdevice through the network, stores management information including theacquired attribute information in a second storage unit, receives therecord file transmitted from the first device according to the transfercondition after acquiring the attribute information of the record file,stores the received record file in the second storage unit, and updatesthe management information stored in the second storage unitcorresponding to the identification information of the received recordfile.
 2. The file management system according to claim 1, wherein thefirst device comprising: a record file creation unit for creating therecord file including the voice data or the image data, an attributefile creation unit for creating an attribute file including an attributeinformation indicating the attribute of the record file and includingthe identification given to the record file, a first storage unit forstoring the record file which has been created by the record filecreation unit under condition that the record file is associated withthe identification, and a transfer control unit for controlling transferof the record file and the attribute file to the second device; andwherein the second device comprising: an attribute processing unit foracquiring the attribute information of the attribute file transmittedthrough the network, a management unit for creating managementinformation including the attribute information acquired by theattribute processing unit, a second storage unit for storing themanagement information created by the management unit and the recordfile transmitted by the first device through the network, and a transfercondition setting unit for setting beforehand the transfer condition onwhich the record file stored in the first storage of the first device istransferred to the second device, and wherein the first device transfersthe record file stored in the first storage unit to the second deviceaccording to the transfer condition after transmitting the attributefile corresponding to the record file from the first device to thesecond device, wherein the second device stores the received the recordfile in the second storage unit, wherein the management unit updatesinformation at the storage location of the record file in the attributeinformation of the management information corresponding to the recordfile when the second device receives the record file transmitted fromthe first device and stores in the second storage unit.
 3. The filemanagement system according to claim 1, wherein the first device isconnected to a telephone system for reception and response of telephonecommunication through a public telephone network, and wherein the firstdevice creates the record voice file generated in the telephone systemand the attribute information associated with the record voice file. 4.The file management system according to claim 1, wherein the firstdevice or the second device stores a transfer condition tableregistering the transfer condition in the first storage unit or thesecond storage unit respectively, and wherein the transfer condition canbe set or changed from a terminal connected to the first device or thesecond device.
 5. The file management system according to claim 4,wherein the time zone that network bandwidth is readily ensured when oneor multiple items included in the attribute information of themanagement information and/or the record file are transferred to thesecond device, is set as the transfer condition registered in thetransfer condition table.
 6. The file management system according toclaim 5, wherein the second device acquires the attribute information (afirst attribute information) acquired from the first device and otherattribute information (a second attribute information) related to thefirst attribute information from another device different from the firstdevice, and stores in the second storage unit under condition that thefirst attribute information and the second attribute information iscorresponded respectively, and wherein the time when one or multipleitems included in the attribute information of the managementinformation and/or the record file are transferred to the second device,is set as the transfer condition registered in the transfer conditiontable.
 7. The file management system according to claim 2, wherein whenthe second device receives the record file from the first device, themanagement unit changes the condition of the record file in theattribute information of the management information corresponding to therecord file into the condition of reception finished for the recordfile, and changes the information of the storage location of the recordfile into the location in the second storage unit.
 8. The filemanagement system according to claim 2, wherein the second storage unitstores a management table managing the management information includingan identification for identifying the record file, an address forspecifying the storage location in the first storage unit at which therecord file is stored and a reception flag indicating whether the recordfile is received or not, and wherein the management unit registers tothe management table the identification for identifying the record file,and the address for specifying the storage location in the first storageunit acquired from the attribute information.
 9. The file managementsystem according to claim 2, wherein the record file is left in thefirst storage after transferring the record file from the first deviceto the second device, and wherein the first device transfers the recordfile stored in the first storage to a terminal connected to the firstdevice in accordance with a request from the terminal.
 10. The filemanagement system according to claim 2, wherein the second storage unitstores a management table managing the management information includingan identification for identifying the record file, an address forspecifying the storage location in the first storage unit at which therecord file is stored and a cash flag indicating whether the record fileexits in the first storage or not, and wherein the record file is leftin the first storage even after transferring the record file from thefirst device to the second device, and wherein the management unit makesthe cash flag “effective”, the first device transfers the record filestored in the first storage to a terminal connected to the first devicein accordance with a request from the terminal.
 11. A file managementmethod that transmits a record file of voice data or image data which iscreated by a first device to a second device over a network and managesthe record file in the second device, wherein the first device: createsthe record file including the voice data or the image data, creates anattribute information indicating the attribute file of the record file,stores the record file associated with information identifying therecord file in a first storage unit, and transmits the attributeinformation including the identification information about the recordfile to the second device through the network, the first device or thesecond device beforehand sets the transfer condition on which the recordfile stored in the first storage is transferred to the second device;wherein the second device: acquires the attribute informationtransmitted from the first device through the network, stores managementinformation including the acquired attribute information in a secondstorage unit, receives the record file transmitted from the first deviceaccording to the transfer condition after acquiring the attributeinformation of the record file, stores the received record file in thesecond storage unit, and updates the management information stored inthe second storage unit corresponding to the identification informationof the received record file.
 12. The file management method according toclaim 11, wherein according to a request from a terminal connected tothe second device, the second device transmits the attribute informationincluded in the management information stored in the second storage unitto the terminal, wherein the terminal issues a request for acquiring therecord file to the first device or the second device based on theacquired attribute information, and wherein the first device or thesecond device receiving the acquisition request reads the record filestored in the first storage or the second storage respectively, andtransmits to the terminal.
 13. A file management system that transmits arecord file of voice data or image data which is created by a firstdevice to a second device over a network and manages the record file inthe second device, wherein the second device: beforehand sets thetransfer condition that the record file is transferred to the firstdevice stored in the first storage of the first device, acquiresattribute information indicating attribute of the record file, includingthe identification for identifying with the record file, and transmittedfrom the first device through the network, stores management informationincluding the acquired attribute information in a storage unit, receivesthe record file transmitted from the first device according to thetransfer condition after acquiring the attribute information of therecord file, stores the record file in the second storage unit, andupdates the management information stored in the storage unitcorresponding to the identification information of the received recordfile.
 14. A file management method that transmits a record file of voicedata or image data which is created by a first device to a second deviceover a network and manages the record file in the second device, whereinthe second device: beforehand sets the transfer condition that therecord file is transferred to the first device stored in the firststorage of the first device, acquires attribute information indicatingattribute of the record file, including the identification foridentifying with the record file, and transmitted from the first devicethrough the network, stores management information including theacquired attribute information in a storage unit, receives the recordfile transmitted from the first device according to the transfercondition after acquiring the attribute information of the record file,stores the record file in the second storage unit, and updates themanagement information stored in the storage unit corresponding to theidentification information of the received record file.
 15. A computerreadable medium having stored therein a file management program thattransmits a record file of voice data or image data which is created bya first server to a second server over a network and manages the recordfile in the second server, a first program is executed by the firstserver, wherein the first program: creates the record file including thevoice data or the image data, creates an attribute informationindicating attribute about the record file, stores the record fileassociated with information identifying the record file in a firststorage unit, and transmits the attribute information including theidentification information about the record file to the second serverthrough the network, the first server or the second server beforehandsets the transfer condition on which the record file is transferred tothe first server stored in the first storage of the first server, asecond program is executed by the second server, wherein the secondprogram: acquires the attribute information transmitted from the firstserver through the network, stores management information including theacquired attribute information in a second storage unit, receives therecord file transmitted from the first server according to the transfercondition after acquiring the attribute information of the record file,stores the received record file in the second storage unit, and updatesthe management information stored in the second storage unitcorresponding to the identification information of the received recordfile.